.gitignore (3)

67-67: Redis 아티팩트 전반 무시 패턴으로 확장 권장

dump.rdb 하나만 무시하면 append-only 파일(AOF)·임시 RDB 등이 남습니다. Redis 버전/설정에 따라 파일명이 달라지므로 포괄 패턴으로 관리하는 편이 안전합니다.

적용 제안(diff):

-redis-data/dump.rdb
+redis-data/*.rdb
+redis-data/temp-*.rdb
+redis-data/*.aof
+redis-data/appendonly*.aof*

운영/빌드 컨텍스트 축소를 위해 동일 패턴을 .dockerignore에도 반영하는 것을 권장합니다.

---

69-69: stage 환경 설정 무시 OK — 템플릿 파일을 버전에 포함하세요

실파일은 무시하되 팀 합의를 위해 예시 템플릿을 추적하는 것을 권장합니다.

적용 제안(diff):

 src/main/resources/application-stage.yml
+!src/main/resources/application-stage.example.yml

README/운영 문서에 “example를 복사해 실제 값을 채우고 파일명은 application-stage.yml로” 절차를 추가해 주세요. CI가 stage 프로파일을 요구한다면 환경변수/시크릿 기반 주입으로 전환하는 것도 고려 바랍니다.

---

71-71: 부하 테스트 스크립트는 추적 유지 권장; 결과물만 무시

테스트 스크립트(k6/settlement_test.js)를 무시하면 팀 공유·재현성이 떨어집니다. 스크립트는 추적하고 결과 디렉터리만 무시하세요.

적용 제안(diff):

-k6/settlement_test.js
+k6/results/**
+k6/*.html

이미 커밋된 스크립트를 그대로 유지하고 결과물만 무시하면 됩니다. 의도적으로 제외한 것이라면 사유를 PR 설명에 명시해 주세요.

.dockerignore (1)

1-6: Docker 빌드 컨텍스트 더 줄이기(빌드 산출물만 포함).

현재 build 디렉터리가 제외되지 않아 컨텍스트가 커질 수 있습니다. 빌드 산출물 JAR만 포함하도록 아래 예외 규칙을 추가하는 것을 권장합니다.

 .gradle
 target
 out
 node_modules
 *.iml
 *.log
+build
+!build/libs/*.jar
+.git
+.idea
+*.class
+.DS_Store

src/main/java/com/example/onlyone/domain/schedule/dto/response/ScheduleDetailResponseDto.java (1)

18-18: Long 전환은 적절. 단, null 불가 보장 필요.

Line 18: DTO에서 Long(래퍼) 사용 시 null이 직렬화/클라이언트 파싱 문제를 일으킬 수 있습니다. 생성 경로에서 항상 값 세팅을 보장하거나, Bean Validation(@NotNull)로 컨트롤러 입력을 검증해 주세요. 금액 단위(KRW, 분 단위 등)도 주석/스키마로 명시 권장.

src/main/java/com/example/onlyone/domain/user/dto/response/MySettlementDto.java (1)

16-16: amount Long 전환 OK. 주석된 from(...)는 구 스펙 혼동 유발 → 제거/갱신 권장.

Line 16: Long 사용은 일관성 측면에서 좋습니다. null 허용 시 기본값(0L) 정책을 명확히 해 주세요.
Lines 22-30: 주석 블록이 현재 필드명과 불일치(예: settlementId)합니다. 제거하거나 최신 스펙으로 갱신해 주세요.

Also applies to: 22-30

src/main/java/com/example/onlyone/domain/user/dto/response/MyPageResponse.java (1)

35-35: balance Long 전환 OK. 초기값 보장 필요.

Line 35: 클라이언트 호환성을 위해 null 대신 0L을 반환하는 정책을 권장합니다. DTO 빌더 기본값 또는 응답 조립 시 기본값 세팅을 고려해 주세요.

-    private Long balance;
+    @Builder.Default
+    private Long balance = 0L;

src/main/java/com/example/onlyone/domain/schedule/entity/Schedule.java (1)

41-41: Long 전환 OK. 금액 유효성 제약(0 이상) 명시 권장.

Line 41: 도메인 제약을 엔티티 수준에서도 명시하면 안정적입니다(예: 0 이상).

+import jakarta.validation.constraints.PositiveOrZero;
...
-    @NotNull
-    private Long cost;
+    @NotNull
+    @PositiveOrZero
+    private Long cost;

src/main/resources/luascript/wallet_gate_acquire.lua (1)

2-3: TTL 검증 추가 제안(에러 예방).

EX 0/음수 전달 시 Redis SET이 에러를 던질 수 있어, Lua에서 사전 검증을 권장합니다. 반환 타입은 그대로 유지합니다.

--- KEYS[1] = gate key, ARGV[1] = ttlSec, ARGV[2] = owner
-local ok = redis.call('set', KEYS[1], ARGV[2], 'EX', ARGV[1], 'NX')
-if ok then return 1 else return 0 end
+local ttl = tonumber(ARGV[1])
+if ttl == nil or ttl <= 0 then return 0 end
+local ok = redis.call('set', KEYS[1], ARGV[2], 'EX', ttl, 'NX')
+if ok then return 1 else return 0 end

src/main/java/com/example/onlyone/domain/wallet/entity/Wallet.java (1)

47-49: updateBalance(Long)에서 null/음수 수용 — 방어 로직 추가 권장

파라미터를 primitive로 바꾸고 음수 방지 체크를 추가하세요.

-    public void updateBalance(Long balance) {
-        this.postedBalance = balance;
-    }
+    public void updateBalance(long balance) {
+        if (balance < 0) {
+            throw new IllegalArgumentException("balance must be >= 0");
+        }
+        this.postedBalance = balance;
+    }

src/main/java/com/example/onlyone/domain/schedule/dto/request/ScheduleRequestDto.java (1)

21-22: 금액 Long 전환 👍; 검증은 @PositiveOrZero가 더 표현력 있음

의미상 더 직관적인 애노테이션으로 교체를 제안합니다. 동작은 동일합니다.

-    @Min(value = 0, message = "정기 모임 금액은 0원 이상이어야 합니다.")
-    private Long cost;
+    @PositiveOrZero(message = "정기 모임 금액은 0원 이상이어야 합니다.")
+    private Long cost;

src/main/java/com/example/onlyone/domain/settlement/dto/event/WalletCaptureSucceededEvent.java (1)

6-15: 이벤트 역직렬화 호환성 확보(@NoArgsConstructor 추가 권장)

Kafka/Outbox에서 Jackson 역직렬화를 한다면 기본 생성자가 없어서 실패할 수 있습니다. 무해한 기본 생성자를 추가하세요.

-import lombok.AllArgsConstructor;
-import lombok.Data;
+import lombok.AllArgsConstructor;
+import lombok.Data;
+import lombok.NoArgsConstructor;

 @Data
 @AllArgsConstructor
+@NoArgsConstructor
 public class WalletCaptureSucceededEvent {

src/main/java/com/example/onlyone/global/config/RedisLuaConfig.java (1)

9-9: 불필요한 import 제거

사용되지 않는 java.util.List import를 제거해 주세요.

-import java.util.List;

src/main/java/com/example/onlyone/global/exception/ErrorCode.java (1)

84-84: 409(중복/경합) 재시도 가이던스 제안

WALLET_OPERATION_IN_PROGRESS는 클라이언트 재시도가 전제됩니다. 응답 헤더에 Retry-After(또는 바디에 재시도 지연 힌트)를 싣도록 API 계층에서 표준화하면 UX/트래픽에 이점이 있습니다.

src/main/java/com/example/onlyone/domain/settlement/dto/event/SettlementProcessEvent.java (1)

8-19: Jackson 역직렬화 호환성 보완 권장

final 필드 + all‑args만 있을 경우 환경에 따라 역직렬화 실패가 납니다. 안전하게 기본 생성자를 추가하세요(접근 제한+force).

-import lombok.AllArgsConstructor;
-import lombok.Data;
+import lombok.AllArgsConstructor;
+import lombok.Data;
+import lombok.NoArgsConstructor;
+import lombok.AccessLevel;
@@
-@Data
-@AllArgsConstructor
+@Data
+@AllArgsConstructor
+@NoArgsConstructor(force = true, access = AccessLevel.PROTECTED)
 public class SettlementProcessEvent {

대안: @Builder + @Jacksonized 조합도 고려 가능합니다.

src/main/java/com/example/onlyone/domain/settlement/repository/SettlementRepository.java (1)

28-34: JPQL에서 enum 비교를 FQN enum 상수로 변경하세요

검증: Settlement.totalStatus는 src/main/java/com/example/onlyone/domain/settlement/entity/Settlement.java에서 @Enumerated(EnumType.STRING)로 매핑되어 있어 현재 쿼리는 정상 동작합니다. 다만 매핑이 ORDINAL로 변경되면 쿼리가 깨지므로 JPQL에서 문자열 리터럴('COMPLETED') 대신 FQN enum 상수로 비교하도록 변경하세요.

위치: src/main/java/com/example/onlyone/domain/settlement/repository/SettlementRepository.java (lines 28-34)

-    @Query("UPDATE Settlement s " +
-            "SET s.totalStatus = :status, s.completedTime = :time " +
-            "WHERE s.settlementId = :id AND s.totalStatus <> 'COMPLETED'")
+    @Query("UPDATE Settlement s " +
+            "SET s.totalStatus = :status, s.completedTime = :time " +
+            "WHERE s.settlementId = :id AND s.totalStatus <> com.example.onlyone.domain.settlement.entity.TotalStatus.COMPLETED")
     int markCompleted(@Param("id") Long id,
                       @Param("status") TotalStatus status,
                       @Param("time") LocalDateTime time);

src/main/java/com/example/onlyone/domain/settlement/dto/event/WalletCaptureFailedEvent.java (1)

12-12: 데이터 타입 일관성 검토가 필요합니다.

amount 필드가 int 타입인데, 다른 이벤트 클래스들과 PR 전반의 변경사항을 보면 금액 필드가 Long으로 변경되고 있습니다. 일관성을 위해 Long 타입 사용을 검토해보세요.

-    private int amount;
+    private Long amount;

src/main/java/com/example/onlyone/domain/wallet/dto/response/UserWalletTransactionDto.java (1)

20-21: amount의 Long 전환 OK. 프런트/외부 API와 정수 범위 합의 필요.

JS Number의 안전 정수 범위(±9,007,199,254,740,991) 이슈가 있을 수 있습니다. 금액이 해당 범위를 넘지 않는지, 또는 직렬화 정책(예: 문자열) 합의가 되어있는지 확인해 주세요.

Also applies to: 29-31

src/main/java/com/example/onlyone/domain/payment/service/PaymentService.java (1)

126-163: 오토 언박싱 NPE 가능성 제거.

claimPayment(String orderId, long amount)은 primitive long을 받습니다. req.getAmount()가 null이면 NPE가 납니다. DTO에 @NotNull 보장 또는 시그니처를 Long으로 바꾸고 null 검증을 추가하세요.

-    private Payment claimPayment(String orderId, long amount) {
+    private Payment claimPayment(String orderId, Long amount) {
+        if (amount == null) throw new CustomException(ErrorCode.INVALID_PAYMENT_INFO);

src/main/java/com/example/onlyone/domain/wallet/entity/WalletTransaction.java (2)

33-40: 널 제약을 DB 레벨까지 반영.

현재 @NotNull만 있고 @column(nullable = false)가 없어 DDL에 반영되지 않을 수 있습니다.

-    @Column(name = "amount")
+    @Column(name = "amount", nullable = false)
     @NotNull
     private Long amount;

-    @Column(name = "balance")
+    @Column(name = "balance", nullable = false)
     @NotNull
     private Long balance;

Also applies to: 41-45

---

81-88: update(...)에서 targetWallet 강제 동일 설정은 범용성 저하.

충전 이외(이체 등)에서 targetWallet이 다를 수 있는데, 현재 메서드는 동일 지갑으로 덮어씌웁니다. 호출부에서 명시하지 않으면 오동작 위험이 있습니다. 파라미터 분리 또는 타입별 분기로 개선하세요.

-    public void update(Type type, Long amount, Long postedBalance, WalletTransactionStatus walletTransactionStatus, Wallet wallet) {
+    public void update(Type type, Long amount, Long postedBalance, WalletTransactionStatus walletTransactionStatus, Wallet wallet) {
         this.type = type;
         this.amount = amount;
         this.balance = postedBalance;
         this.walletTransactionStatus = walletTransactionStatus;
         this.wallet = wallet;
-        this.targetWallet = wallet;
+        // CHARGE인 경우에만 동일 지갑 설정(필요 시 호출부에서 명시적으로 설정)
+        if (type == Type.CHARGE) {
+            this.targetWallet = wallet;
+        }
     }

src/main/java/com/example/onlyone/domain/settlement/dto/event/UserSettlementStatusEvent.java (1)

9-17: 역직렬화/호환성 강화를 위한 NoArgsConstructor 추가 및 타입 일관성.

다른 서비스/컨슈머에서 Jackson 역직렬화 시 기본 생성자가 없으면 실패할 수 있습니다. 또한 금액 타입을 Long으로 통일하면 내부 도메인과 일관성이 높습니다.

 @Data
-@AllArgsConstructor
+@AllArgsConstructor
+@lombok.NoArgsConstructor
 @JsonIgnoreProperties(ignoreUnknown = true)
 public class UserSettlementStatusEvent {
     public enum ResultType { SUCCESS, FAILED }
@@
-    private long amount;
+    private Long amount;
@@
     @Data
     public static class Snapshots {
         private Long memberPostedBalance;
         private Long leaderPostedBalance;
     }

Also applies to: 29-34

src/main/java/com/example/onlyone/global/config/kafka/KafkaErrorConfig.java (1)

14-21: @qualifier 불필요 — KafkaTemplate 빈은 단일입니다.

src/main/java/com/example/onlyone/global/config/kafka/KafkaProducerConfig.java:57 에 ledgerKafkaTemplate() 빈 한 개 확인. 따라서 NoUniqueBeanDefinitionException 우려 없음. DefaultErrorHandler에 handler.addNotRetryableExceptions(IllegalArgumentException.class) 등록은 선택적 권장.

src/main/java/com/example/onlyone/domain/settlement/service/KafkaService.java (2)

26-30: groupId 하드코딩 → 구성 일원화 필요

컨슈머 팩토리에서 props의 groupId를 이미 사용 중인데, @KafkaListener에 "ledger-writer"로 하드코딩되어 불일치가 날 수 있습니다(운영/스테이징 분기 곤란).

-            groupId = "ledger-writer",
+            groupId = "#{@kafkaProperties.consumer.commonConfig.groupId}",

---

22-30: 관측성 보강 제안(배치 크기/파트션/오프셋 로그 및 메트릭)

운영 트러블슈팅을 위해 records.size(), topic/partition, first/last offset 등을 info/debug로 남기거나 micrometer 카운터 추가를 권장합니다.

src/main/java/com/example/onlyone/global/config/kafka/OutboxRelayConfig.java (3)

23-25: 스케줄 주기 하드코딩

fixedDelay 200ms는 환경별로 튜닝이 필요합니다. 프로퍼티화하여 운영에서 조정 가능하도록 하세요.

-    @Scheduled(fixedDelay = 200)
+    @Scheduled(fixedDelayString = "${outbox.relay.fixed-delay-ms:200}")

추가로 배치 크기도 프로퍼티로 외부화 권장.

---

36-40: 상태 전이 실패 시 상태 기록 부재

send 단계 예외 발생 시 상태가 그대로 NEW로 남아 무한 재시도는 가능하지만, 실패 원인/횟수 추적이 어렵습니다.

• 실패 카운터/lastError 필드 추가 또는 로그/메트릭에 원인 기록.
• 필요 시 FAILED 상태 도입과 백오프 재시도.

---

42-50: routeTopic에서 프로듀서/컨슈머 설정 혼용

ParticipantSettlementResult를 컨슈머 설정(props.consumer.userSettlementLedgerConsumerConfig.topic)에서 가져오고, SettlementProcessEvent는 프로듀서 설정에서 가져옵니다. 구성 일관성이 떨어집니다.

• 토픽 소스를 단일 영역(예: props.topics.* 또는 producer 쪽)으로 통일 검토를 요청드립니다.

이 변경이 다른 환경(yaml)에서 정상 값으로 해석되는지 확인 부탁드립니다.

src/main/java/com/example/onlyone/domain/wallet/service/WalletService.java (1)

83-109: Long 전환은 적절하나, 잔액 스냅샷/operationId 확인 필요

• balance를 postedBalance 스냅샷으로 저장하는 현재 방식이 요구사항(정산 시점 잔액)과 일치하는지 확인 바랍니다.
• 새 엔티티에 operationId 필드가 도입된 것으로 보입니다. 본 경로로 생성되는 트랜잭션에도 멱등 식별자(operationId) 부여가 필요한지 검토하십시오(중복 생성 방지).

가능 시 프록시 조회로 일관화:

-        Wallet wallet = walletRepository.findById(walletId).orElseThrow();
-        Wallet leaderWallet = walletRepository.findById(leaderWalletId).orElseThrow();
+        Wallet wallet = walletRepository.getReferenceById(walletId);
+        Wallet leaderWallet = walletRepository.getReferenceById(leaderWalletId);

src/main/java/com/example/onlyone/domain/settlement/repository/UserSettlementRepository.java (3)

119-128: 메서드명과 반환 값 불일치

SELECT us.user.userId를 반환하는데 메서드명이 findAllUserSettlementIds...라 오해 소지가 큽니다(실제는 participant(user) ID 리스트).

• 명칭을 findAllParticipantIdsBySettlementIdAndStatus 등으로 변경 권장(호출부 영향 확인 필요).

---

129-138: 중복 메서드 존재

findActiveParticipantIds가 위 메서드와 완전히 동일 쿼리/시그니처입니다. 유지보수 혼란을 줄이려면 하나만 남기세요(대체 주석에도 “사용하지 않음” 명시).

• @deprecated 추가 후 제거 또는 즉시 삭제 권장.

---

93-97: 성능/인덱스 확인 요청

settlementId+settlementStatus 조건으로 반복 조회됩니다. 해당 조합에 대한 복합 인덱스가 있는지 확인해 주세요.

원하시면 JPA/Hibernate 실행 계획을 기반으로 인덱스 제안을 드리겠습니다.

Also applies to: 119-128

src/main/java/com/example/onlyone/domain/settlement/service/OutboxAppender.java (3)

20-38: 트랜잭션 전파 전략 재검토

Outbox 이벤트는 일반적으로 도메인 변경과 “같은” 트랜잭션에서 커밋되어야 합니다. 현재 @transactional은 새 트랜잭션을 열 수도 있어, 도메인 변경과 분리될 수 있습니다.

• 도메인 서비스에서 이미 트랜잭션을 연다는 전제라면 MANDATORY로 고정 권장:

-    @Transactional
+    @Transactional(propagation = org.springframework.transaction.annotation.Propagation.MANDATORY)

• 반대로 단독 사용도 필요하면 Javadoc로 사용 컨벤션 명시 또는 오버로드 제공.

---

24-37: 예외 래핑 타입 통일

RuntimeException("Outbox append failed") 대신 프로젝트 표준 CustomException(ErrorCode.*) 사용을 검토해 주세요(로그/오브저버빌리티 일관성).

---

24-31: 페이로드 크기/스키마 검증

대형 페이로드는 Kafka max.request.size/브로커 설정에 막힐 수 있습니다. 직렬화 실패 시 재시도 루프에 들어갈 수 있어, 스키마/크기 밸리데이션(예: 1MB 제한) 추가를 권장합니다.

src/main/java/com/example/onlyone/domain/settlement/dto/event/OutboxEvent.java (2)

1-1: 엔티티가 dto 패키지에 위치

영속 엔티티가 dto.event 패키지에 위치하면 계층 경계가 흐려집니다. entity 패키지로 이동을 권장합니다. 매핑 경로 변경에 따른 import/패키지 의존성만 조정하면 됩니다.

---

26-34: 시간 필드 기본값/제약과 타입 일관성 정비

createdAt/publishedAt가 null 허용입니다. 운영 가시성과 정합성을 위해 null 금지 + 자동 채움이 낫습니다. 또한 시스템 시간대 영향 최소화를 위해 Instant 사용을 고려하세요.

적용 제안(개요):

• @PrePersist로 createdAt 자동 세팅, @Column(nullable = false) 부여
• 필요 시 publishedAt도 상태 전이 시점에서만 세팅
• DB가 지원한다면 payload를 JSON 타입으로 저장하여 인덱싱/검증 이점 확보

src/main/java/com/example/onlyone/domain/settlement/service/SettlementProcessEventListener.java (4)

30-33: Kafka 기반 처리와 기능 중복 가능성 점검

동일 기능이 SettlementKafkaEventListener에도 존재합니다. 실제 트리거 경로(스프링 이벤트 vs. 카프카) 중 하나만 활성이라면 비사용 경로는 제거/프로파일링으로 분리해 복잡도를 줄이세요.

---

56-83: 참가자 루프+재시도 동안 트랜잭션 유지 → 장기 트랜잭션 리스크

메서드에 @Transactional이 걸려 있어 전체 루프(슬립 포함) 동안 트랜잭션이 유지됩니다. 참가자별 처리는 이미 REQUIRES_NEW이므로, 여기서는 최종 집계/상태 갱신 구간만 트랜잭션으로 좁히는 편이 안전합니다.

개선 제안:

• 루프 부분은 비트랜잭션(또는 readOnly)로 수행
• 최종 creditToLeader/스케줄/정산 갱신만 별도 메서드(@transactional)로 분리

---

46-54: 예외 삼키기 방지

실패 시 로깅/모니터링(또는 실패 Outbox) 없이 무시됩니다. 최소한 경고 로그와 컨텍스트(이벤트 ID/settlementId)를 남겨주세요.

적용 제안:

-        } catch (Exception e) {
-            // 필요 시 실패 알림/아웃박스
-        }
+        } catch (Exception e) {
+            log.warn("SettlementProcessEvent handling failed: settlementId={}, scheduleId={}",
+                    event.getSettlementId(), event.getScheduleId(), e);
+            // TODO: 실패 Outbox 기록 또는 알림
+        }

---

43-45: 미사용 필드 제거

EntityManager em이 사용되지 않습니다. 제거하여 노이즈를 줄이세요.

-    @PersistenceContext
-    private EntityManager em;

src/main/java/com/example/onlyone/domain/settlement/service/FailedEventAppender.java (1)

51-63: Outbox 저장 로직 중복 – OutboxAppender 사용으로 DRY

동일 책임(직렬화/OutboxEvent 생성/저장)이 OutboxAppender에 이미 있습니다. 중복 로직을 제거해 유지보수성과 일관성을 높여주세요.

다음과 같이 치환 가능합니다:

-            OutboxEvent event = OutboxEvent.builder()
-                    .aggregateType("UserSettlement")
-                    .aggregateId(userSettlementId)
-                    .eventType("ParticipantSettlementResult")
-                    .keyString(String.valueOf(memberWalletId)) // partition key
-                    .payload(json)
-                    .status(OutboxStatus.NEW)
-                    .createdAt(LocalDateTime.now())
-                    .build();
-
-            outboxRepository.save(event);
+            outboxAppender.append(
+                "UserSettlement",
+                userSettlementId,
+                "ParticipantSettlementResult",
+                String.valueOf(memberWalletId), // partition key
+                json
+            );

src/main/java/com/example/onlyone/domain/settlement/service/SettlementKafkaEventListener.java (1)

94-102: 파싱 실패 원인 로깅 보강 제안

현재 INVALID_EVENT_PAYLOAD로만 래핑됩니다. 최소한 원인(e.getMessage())을 로그로 남겨 운영 가시성을 확보하세요.

src/main/java/com/example/onlyone/domain/settlement/service/SettlementService.java (3)

120-137: 이벤트 스키마의 타입 안정성 확보 (DTO 사용 권장)

현재 Map으로 페이로드를 구성합니다. SettlementProcessEvent DTO를 그대로 사용하면 스키마 드리프트를 방지하고 직렬화 오류를 줄일 수 있습니다.

-        outboxAppender.append(
-                "Settlement",
-                settlement.getSettlementId(),
-                "SettlementProcessEvent",
-                String.valueOf(settlement.getSettlementId()),
-                Map.of(
-                        "eventId", java.util.UUID.randomUUID().toString(),
-                        "occurredAt", java.time.Instant.now().toString(),
-                        "settlementId", settlement.getSettlementId(),
-                        "scheduleId", scheduleId,
-                        "clubId", clubId,
-                        "leaderId", leader.getUserId(),
-                        "leaderWalletId", leaderWallet.getWalletId(),
-                        "costPerUser", schedule.getCost(),
-                        "totalAmount", totalAmount,
-                        "targetUserIds", targetUserIds
-                )
-        );
+        var evt = new SettlementProcessEvent(
+                java.util.UUID.randomUUID().toString(),
+                java.time.Instant.now(),
+                settlement.getSettlementId(),
+                scheduleId,
+                clubId,
+                leader.getUserId(),
+                leaderWallet.getWalletId(),
+                schedule.getCost(),
+                totalAmount,
+                targetUserIds
+        );
+        outboxAppender.append("Settlement", settlement.getSettlementId(),
+                "SettlementProcessEvent", String.valueOf(settlement.getSettlementId()), evt);

---

101-105: 0원/무참가자 분기에서 영속화/상태 일관성 보완

schedule.updateStatus(CLOSED)와 removeSettlement 후 즉시 return 합니다. orphanRemoval/flush 보장이 없다면 상태 일관성이 깨질 수 있습니다. 저장 또는 정산 엔티티 상태 갱신을 명시하세요.

         if (schedule.getCost() == 0 || userCount == 0) {
             schedule.updateStatus(ScheduleStatus.CLOSED);
             schedule.removeSettlement(settlement);
-            return;
+            scheduleRepository.save(schedule);
+            settlementRepository.delete(settlement); // 또는 상태를 CANCELED 등으로 업데이트
+            return;
         }

---

56-58: 미사용 필드 제거 권장

eventPublisher는 사용되지 않습니다. 정리해 경고를 제거하세요.

src/main/java/com/example/onlyone/domain/settlement/service/LedgerWriter.java (3)

77-78: 미사용 변수/맵 제거

walletTransactionHashMap은 쓰이지 않습니다. 제거해 가독성과 메모리 사용을 개선하세요.

-        Map<String, WalletTransaction> walletTransactionHashMap = new HashMap<>();
...
-                walletTransactionHashMap.put(outId, outTransaction);
...
-                walletTransactionHashMap.put(inId, inTransaction);

Also applies to: 107-108, 134-135

---

18-19: 중복 로그 애너테이션 import

@log4j2를 사용 중인데 lombok.extern.java.Log import가 남아있습니다. 정리 바랍니다.

-import lombok.extern.java.Log;

---

155-169: Transfer 배치 실패 시 로깅/개별 재시도 보강

DataIntegrityViolationException을 무시하면 데이터 손실을 은닉할 수 있습니다. 최소한 경고 로그와 실패 카운트/메트릭을 남기고 필요 시 개별 재시도를 수행하세요.

src/main/java/com/example/onlyone/global/config/kafka/KafkaConsumerConfig.java (2)

62-73: 에러 핸들러 일관 설정 제안

DefaultErrorHandler 빈이 있다면 컨테이너에 명시 설정해 운영시 가시성을 높이세요(재시도/DTL 정책 확인 용이).

예:

f.setCommonErrorHandler(defaultErrorHandler());

또한 settlementProcess 컨테이너에도 observationEnabled 설정을 고려해 주세요.

Also applies to: 80-87

---

12-12: 미사용 import 정리

CommonLoggingErrorHandler는 사용되지 않습니다.

-import org.springframework.kafka.listener.CommonLoggingErrorHandler;

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: gkdudans
PR: GoormOnlyOne/OnlyOne-Back#110
File: src/main/java/com/example/onlyone/domain/wallet/entity/WalletTransactionStatus.java:5-5
Timestamp: 2025-08-11T09:51:57.984Z
Learning: In the OnlyOne project's wallet transaction system (WalletTransactionStatus enum in src/main/java/com/example/onlyone/domain/wallet/entity/WalletTransactionStatus.java), the PENDING status is used as a locking mechanism for concurrency control to prevent duplicate transaction processing, not for retry or timeout handling.

Learnt from: gkdudans
PR: GoormOnlyOne/OnlyOne-Back#53
File: src/main/java/com/example/onlyone/domain/schedule/service/ScheduleService.java:52-62
Timestamp: 2025-07-31T06:40:23.207Z
Learning: In the OnlyOne application's ScheduleService, the user has refactored the updateScheduleStatus scheduled method to use JPQL batch update instead of iterating through individual entities for better performance. They are also considering future improvements with Spring Batch or QueryDSL update functionality for more complex batch processing scenarios.

Learnt from: gkdudans
PR: GoormOnlyOne/OnlyOne-Back#96
File: src/main/java/com/example/onlyone/domain/notification/service/NotificationService.java:0-0
Timestamp: 2025-08-08T02:28:30.742Z
Learning: 사용자 gkdudans가 알림 생성 로직에서 트랜잭션 커밋 후 알림 전송을 위해 TransactionalEventListener(phase = AFTER_COMMIT)를 사용하는 것을 선호함. 이는 TransactionSynchronizationManager보다 더 깔끔하고 Spring다운 이벤트 기반 접근법임.

src/main/java/com/example/onlyone/domain/settlement/dto/event/WalletCaptureSucceededEvent.java (1)

12-12: 금액 타입 일관성 정리 완료(LGTM).

기존 코멘트에서 지적된 amount 타입 불일치가 해소되었습니다. 이벤트 DTO 전반이 Long으로 통일되어 직렬화/오버플로 리스크가 줄었습니다.

src/main/java/com/example/onlyone/domain/settlement/dto/event/WalletCaptureFailedEvent.java (1)

6-15: 실패 사유(reason)/시점 누락으로 사후 분석 어려움.

실패 이벤트에 최소한 errorCode/reason, occurredAt을 포함하세요. 운영, 재시도, 알림에서 필수입니다.

 package com.example.onlyone.domain.settlement.dto.event;
 
 import lombok.AllArgsConstructor;
 import lombok.Data;
+import java.time.Instant;
 
 @Data
 @AllArgsConstructor
 public class WalletCaptureFailedEvent {
     private Long userSettlementId;
     private Long memberWalletId;
     private Long leaderWalletId;
     private Long amount;
     private Long memberBalanceBefore;
     private Long leaderBalanceBefore;
+    private String reason;     // ex) "INSUFFICIENT_BALANCE"
+    private Instant occurredAt;
 }

src/main/java/com/example/onlyone/domain/settlement/service/SettlementKafkaEventListener.java (1)

116-121: 인터럽트 친화적 세마포어 획득으로 수정된 점 확인(LGTM).

acquireUninterruptibly() → acquire()로 변경되어 StructuredTaskScope 취소 신호를 존중합니다.

src/main/java/com/example/onlyone/domain/settlement/service/FailedEventAppender.java (1)

23-31: 실패 사유(reason) 페이로드 누락 — 재현됨.

지난 코멘트와 동일 이슈입니다. reason을 메서드 시그니처에 추가하고 JSON에 주입하세요. 또한 파티션 키를 memberWalletId가 아닌 이벤트 키(operationId)로 맞춰 멱등/순서를 보장하는 편이 안전합니다.

-    public void appendFailedUserSettlementEvent(Long settlementId,
+    public void appendFailedUserSettlementEvent(Long settlementId,
                                                 Long userSettlementId,
                                                 Long participantId,
                                                 Long memberWalletId,
                                                 Long leaderId,
                                                 Long leaderWalletId,
-                                                Long amount) {
+                                                Long amount,
+                                                String reason) {
         try {
-            // 1. DTO로 변환
+            // 1. DTO로 변환
+            String eventKey = "stl:%d:usr:%d:v1".formatted(settlementId, participantId);
             UserSettlementStatusEvent eventDto = new UserSettlementStatusEvent(
                     UserSettlementStatusEvent.ResultType.FAILED,
-                    "stl:%d:usr:%d:v1".formatted(settlementId, participantId),
+                    eventKey,
                     Instant.now(),
                     settlementId,
                     userSettlementId,
                     participantId,
                     memberWalletId,
                     leaderId,
                     leaderWalletId,
                     amount
             );
 
-            // 2. JSON 직렬화
-            String json = objectMapper.writeValueAsString(eventDto);
+            // 2. JSON 직렬화 (+reason 주입)
+            var node = objectMapper.valueToTree(eventDto);
+            ((com.fasterxml.jackson.databind.node.ObjectNode) node).put("reason", reason);
+            String json = objectMapper.writeValueAsString(node);
 
             // 3. OutboxEvent 저장
             OutboxEvent event = OutboxEvent.builder()
                     .aggregateType("UserSettlement")
                     .aggregateId(userSettlementId)
                     .eventType("ParticipantSettlementResult")
-                    .keyString(String.valueOf(memberWalletId)) // partition key
+                    .keyString(eventKey) // partition key = operationId
                     .payload(json)
                     .status(OutboxStatus.NEW)
                     .createdAt(LocalDateTime.now())
                     .build();

src/main/java/com/example/onlyone/domain/settlement/service/UserSettlementService.java (1)

100-106: FAILED 상태 업데이트가 롤백됨 → 이벤트/상태 불일치 가능.

현재 메서드 전체가 REQUIRES_NEW이므로 catch에서 상태를 FAILED로 바꾼 뒤 예외를 던지면 동일 트랜잭션 롤백으로 상태 변경이 사라집니다. 반면 FailedEventAppender는 별도(REQUIRES_NEW)로 커밋되어 불일치가 발생할 수 있습니다. 별도 트랜잭션에서 상태를 저장하세요.

-            } catch (Exception e) {
-                userSettlementRepository.updateStatusIfRequested(us.getUserSettlementId(), SettlementStatus.FAILED);
-                failedEventAppender.appendFailedUserSettlementEvent(
-                        settlementId, us.getUserSettlementId(), participantId,
-                        memberWalletId, leaderId, leaderWalletId, amount
-                );
-                throw e;
-            }
+            } catch (Exception e) {
+                // 1) 상태는 별도 트랜잭션에서 확정
+                markUserSettlementFailedInNewTx(us.getUserSettlementId());
+                // 2) 실패 이벤트는 예외 삼켜서 원본 예외 보존 + reason 전달
+                try {
+                    failedEventAppender.appendFailedUserSettlementEvent(
+                            settlementId, us.getUserSettlementId(), participantId,
+                            memberWalletId, leaderId, leaderWalletId, amount,
+                            e.getClass().getSimpleName()
+                    );
+                } catch (Exception appendEx) {
+                    log.warn("Failed to append FAILED event (userSettlementId={}): {}", us.getUserSettlementId(), appendEx.getMessage(), appendEx);
+                }
+                throw e;
+            }

추가(클래스 내부, 선택 영역 밖):

@Transactional(propagation = Propagation.REQUIRES_NEW)
void markUserSettlementFailedInNewTx(Long userSettlementId) {
    userSettlementRepository.updateStatusIfRequested(userSettlementId, SettlementStatus.FAILED);
}

src/main/java/com/example/onlyone/domain/wallet/entity/WalletTransaction.java (1)

25-26: operationId 컬럼: 길이/NULL/업데이트 불가 제약 추가 필요

중복 방지 키로 쓰이므로 DB 스키마 보강이 필요합니다. 현재 unique만 있고 길이/NULL/업데이트 불가가 없습니다.

적용 제안(diff):

-    @Column(name = "operation_id", unique = true)
-    private String operationId;
+    @Column(name = "operation_id", length = 128, nullable = false, updatable = false, unique = true)
+    @NotNull
+    private String operationId;

DB 마이그레이션(DDL)로도 동일 제약(length/NOT NULL/UNIQUE INDEX) 추가 부탁드립니다. 필요 시 스크립트 생성 도와드릴게요.

src/main/java/com/example/onlyone/domain/settlement/dto/event/WalletCaptureSucceededEvent.java (1)

6-14: 이벤트 스키마에 식별·시점 메타데이터 추가 제안(선택).

하류(idempotency/모니터링)에서 유용한 operationId, occurredAt(Instant) 필드를 포함하면 추적성이 좋아집니다. 필요 시 아래처럼 확장하세요.

 package com.example.onlyone.domain.settlement.dto.event;
 
 import lombok.AllArgsConstructor;
 import lombok.Data;
+import java.time.Instant;
 
 @Data
 @AllArgsConstructor
 public class WalletCaptureSucceededEvent {
     private Long userSettlementId;
     private Long memberWalletId;
     private Long leaderWalletId;
     private Long amount;
     private Long memberBalanceAfter;
     private Long leaderBalanceAfter;
+    private String operationId;   // ex) "stl:%d:usr:%d:v1"
+    private Instant occurredAt;
 }

src/main/java/com/example/onlyone/domain/settlement/service/FailedEventAppender.java (1)

16-22: OutboxAppender 재사용으로 중복 제거 제안.

동일한 outbox 저장 로직이 OutboxAppender에 이미 있습니다. 해당 빈을 주입해 append(...)를 호출하면 코드 중복과 예외 처리 표준화가 됩니다.

src/main/java/com/example/onlyone/domain/settlement/service/SettlementKafkaEventListener.java (1)

82-92: 배치 처리 중 일부 성공/일부 실패 시 재처리 전략 명확화 필요.

현재는 하나라도 실패하면 ack 미호출로 배치 전체가 재소비됩니다. 이미 성공한 이벤트의 재처리를 허용할 멱등키가 없다면 중복 효과가 날 수 있습니다. DLQ/재시도 토폴로지를 분리하거나, 레코드 단위 에러 핸들러를 고려하세요.

src/main/java/com/example/onlyone/domain/settlement/service/UserSettlementService.java (2)

81-99: Outbox 키를 operationId로 통일하여 멱등·순서를 보장.

현재 keyString이 memberWalletId입니다. 소비자 측 dedupe/순서를 안정적으로 하려면 operationId("stl:%d:usr:%d:v1")를 키로 사용하는 편이 적절합니다.

                 outboxAppender.append(
                         "UserSettlement",
                         us.getUserSettlementId(),
                         "ParticipantSettlementResult",
-                        String.valueOf(memberWalletId),
+                        operationId,
                         Map.of(
                                 "type", "SUCCESS",
                                 "operationId", operationId,
                                 "occurredAt", java.time.Instant.now().toString(),
                                 "settlementId", settlementId,
                                 "userSettlementId", us.getUserSettlementId(),
                                 "participantId", participantId,
                                 "memberWalletId", memberWalletId,
                                 "leaderId", leaderId,
                                 "leaderWalletId", leaderWalletId,
                                 "amount", amount
                         )
                 );

---

81-99: Map.of 항목 수 한계(최대 10개) 근접 — 향후 필드 추가 시 실패 위험.

현재 10개로 한계치입니다. 필드가 늘 가능성이 있으면 Map.ofEntries로 변경해 미래 오류를 방지하세요.

-                        Map.of(
-                                "type", "SUCCESS",
-                                "operationId", operationId,
-                                "occurredAt", java.time.Instant.now().toString(),
-                                "settlementId", settlementId,
-                                "userSettlementId", us.getUserSettlementId(),
-                                "participantId", participantId,
-                                "memberWalletId", memberWalletId,
-                                "leaderId", leaderId,
-                                "leaderWalletId", leaderWalletId,
-                                "amount", amount
-                        )
+                        Map.ofEntries(
+                                Map.entry("type", "SUCCESS"),
+                                Map.entry("operationId", operationId),
+                                Map.entry("occurredAt", java.time.Instant.now().toString()),
+                                Map.entry("settlementId", settlementId),
+                                Map.entry("userSettlementId", us.getUserSettlementId()),
+                                Map.entry("participantId", participantId),
+                                Map.entry("memberWalletId", memberWalletId),
+                                Map.entry("leaderId", leaderId),
+                                Map.entry("leaderWalletId", leaderWalletId),
+                                Map.entry("amount", amount)
+                        )

src/main/java/com/example/onlyone/domain/settlement/service/LedgerWriter.java (6)

18-19: 중복 로깅 라이브러리 임포트 정리

@log는 미사용이고 @log4j2만 사용 중입니다. 불필요 임포트 제거하세요.

-import lombok.extern.java.Log;
 import lombok.extern.log4j.Log4j2;

---

66-72: operationId 후보 수집: 네이밍/로깅/검증 강화

• 변수명 오타(candidateoperationIds) → candidateOperationIds.
• 빈/공백 operationId 스킵 시 경고 로그 남기기.

-        Set<String> candidateoperationIds = new HashSet<>();
+        Set<String> candidateOperationIds = new HashSet<>();
         for (JsonNode root : events) {
             String operationId = root.path("operationId").asText();
-            if (operationId == null || operationId.isBlank()) continue;
-            candidateoperationIds.add(operationId + ":OUT");
-            candidateoperationIds.add(operationId + ":IN");
+            if (operationId == null || operationId.isBlank()) {
+                log.warn("Skip event without operationId: {}", root);
+                continue;
+            }
+            candidateOperationIds.add(operationId + ":OUT");
+            candidateOperationIds.add(operationId + ":IN");
         }

그리고 아래 조회부도 변수명 일치:

-        Set<String> existing = new HashSet<>(walletTransactionRepository.findExistingOperationIds(candidateoperationIds));
+        Set<String> existing = new HashSet<>(walletTransactionRepository.findExistingOperationIds(candidateOperationIds));

---

77-140: 동일 배치 내 중복 생성 사전 차단(seen 세트 도입)

DB 중복은 unique로 막히지만 saveAll에서 예외→fallback 경로로 빠져 성능/복잡도를 악화시킵니다. 동일 배치에서 outId/inId를 한 번만 생성하도록 seen 집합으로 차단하세요.

적용 제안(diff):

-        Map<String, WalletTransaction> walletTransactionHashMap = new HashMap<>();
+        Set<String> seen = new HashSet<>(existing);
         for (JsonNode root : events) {
             String type = root.path("type").asText("SUCCESS");
             String operationId = root.path("operationId").asText();
             if (operationId == null || operationId.isBlank()) continue;

@@
             // OUTGOING
             String outId = operationId + ":OUT";
-            if (!existing.contains(outId)) {
+            if (!existing.contains(outId) && seen.add(outId)) {
                 WalletTransaction outTransaction = WalletTransaction.builder()
@@
                 walletTransactionList.add(outTransaction);
-                walletTransactionHashMap.put(outId, outTransaction);
@@
             }
             // INCOMING
             String inId = operationId + ":IN";
-            if (!existing.contains(inId)) {
+            if (!existing.contains(inId) && seen.add(inId)) {
                 WalletTransaction inTransaction = WalletTransaction.builder()
@@
                 walletTransactionList.add(inTransaction);
-                walletTransactionHashMap.put(inId, inTransaction);
@@
             }

또한 미사용 변수 walletTransactionHashMap은 제거하세요.

---

152-166: Transfer 저장 예외 삼킴: 가시성 부족

DataIntegrityViolationException을 무시하면 원인 분석이 어렵습니다. 최소 warn 로그를 남기고 필요 시 개별 재시도하세요.

-            } catch (DataIntegrityViolationException dup) {
-                // 필요시 개별 재시도
-            }
+            } catch (DataIntegrityViolationException dup) {
+                log.warn("Transfer batch save failed, will skip duplicates. size={}", transferList.size(), dup);
+                // 필요 시 개별 재시도 로직 추가 고려
+            }

---

89-92: getReferenceById 사용 시 존재하지 않는 참조 처리

존재하지 않는 ID일 경우 지연접근 시점에 예외가 발생합니다. 이벤트 유효성 보장을 위해 존재 확인(findById orExists) 후 명확한 예외/격리 처리를 권장합니다.

---

143-150: saveAll 후 flush 순서 OK, 단 예외 시 컨텍스트 정리 필요

예외 발생 시 EntityManager clear/close 없이 후속 작업을 계속하면 부작용이 있습니다. 위에서 제안한 트랜잭션 경계 재설계와 함께 고려하세요.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro